Automatically Modifying a Native Code Module Accessed from Virtual Machine Bytecode to Determine Execution Information

ABSTRACT

A system and method for automatically modifying a native code module accessed in a user software application are described herein. The user software application may include virtual machine bytecode. Access to the native code module may be detected during execution of the virtual machine bytecode. The native code module may be automatically modified by adding instrumentation code to determine various types of information regarding execution of the native code module, and the access may be directed to the modified native code module.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to computer software. Moreparticularly, the invention relates to a system and method forintercepting programmatic access of a native code module performedduring execution of virtual machine bytecode and modifying the nativecode module by adding additional code operable to determine informationregarding execution of the native code module.

2. Description of the Related Art

Software developers typically create the source code for softwareapplications in a high-level programming language by writing textualprogram statements that specify the application's functionality. Thesource code may then be compiled into executable machine code that canbe executed by a physical processor. This executable machine code isalso referred to as native code because it is formatted so that itexecutes on a specific type of processor using that processor'sinstruction set. Thus, native code is typically not portable acrossdifferent types of computing devices, e.g., devices that use differenttypes of processors.

An alternative method of program execution is to compile the source codeinto an intermediate form of code called bytecode, which is a binaryrepresentation of program instructions suitable for execution on aspecific type of virtual machine. The virtual machine itself isimplemented in software and is executed by the processor of the physicalcomputing device. A software application that has been compiled intobytecode instructions may be executed on the virtual machine, e.g., bythe virtual machine dynamically interpreting the bytecode instructions.Alternatively, another level of compilation may be performed. Forexample, some virtual machine runtime environments perform just-in-timecompilation to compile bytecode into native code during execution of thesoftware application.

The virtual machine provides a layer of abstraction between the compiledbytecode and the underlying hardware platform and operating system.Thus, compiling a software application into bytecode rather than nativecode may reduce the software application's dependence on specifichardware. For example, the same bytecode may be executed on severaldifferent types of computing platforms as long as a virtual machine toexecute the bytecode is available on all the respective computingplatforms.

While implementing a software application as virtual machine bytecodemay have advantages in terms of portability, some tasks are impossibleor inefficient to do in bytecode and can be done better using nativecode. Thus, some software applications use both hardware-independentvirtual machine bytecode and native code compiled for a specific type ofcomputing hardware or platform. For example, the software applicationmay be implemented with bytecode where possible, and the bytecode mayinvoke native code routines when it is necessary to use featuresdependent on the host environment.

SUMMARY

Various embodiments of a system and method for automatically modifying anative code module accessed in a software application are describedherein. The software application may include virtual machine bytecode.Access to the native code module may be detected during execution of thevirtual machine bytecode. The native code module may be automaticallymodified in order to determine information regarding execution of thenative code module, and the access may be directed to the modifiednative code module.

In various embodiments the native code module may be automaticallymodified in order to determine any of various kinds of informationregarding execution of the native code module. For example, the nativecode module may be modified by adding additional code (referred toherein as “instrumentation code”) operable to determine one or more of:profiling information for the native code module; debugging informationfor the native code module; tracing information for the native codemodule; monitoring information for the native code module;instrumentation information for the native code module; informationregarding a programmatic call performed by the native code module; aparameter value passed in a programmatic call performed by the nativecode module; etc.

As further examples, the native code module may be modified by addinginstrumentation code operable to determine one or more of: timinginformation for the native code module; invocation count information forthe native code module; performance information for the native codemodule; memory usage information for the native code module; resourceusage information for the native code module; network usage informationfor the native code module; database access information for the nativecode module; data used in the native code module; etc.

In some embodiments the method may further comprise receiving firstvirtual machine bytecode of the software application and automaticallyadding additional bytecode to the first bytecode, where the additionalbytecode is operable to detect the access to the native code module andcause the modification of the native code module. For example, theadditional bytecode may cause the modification of the native code moduleby invoking a software tool that performs the automatic modification ofthe native code module.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the invention can be obtained when thefollowing detailed description is considered in conjunction with thefollowing drawings, in which:

FIG. 1 illustrates one embodiment of the method for automaticallymodifying a native code module accessed from virtual machine bytecode ofa user software application;

FIG. 2 illustrates one embodiment of a computer system configured toimplement the method of FIG. 1;

FIG. 3 is a flowchart diagram illustrating a more particular embodimentof the method of FIG. 1; and

FIG. 4 is a flowchart diagram illustrating one embodiment of a methodfor dynamically adding additional bytecode to an object-oriented classused by the user software application.

While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and are described in detail. It should beunderstood, however, that the drawings and detailed description theretoare not intended to limit the invention to the particular formdisclosed, but on the contrary, the intention is to cover allmodifications, equivalents and alternatives falling within the spiritand scope of the present invention as defined by the appended claims.

DETAILED DESCRIPTION

Various embodiments of a system and method for automatically modifying anative code module accessed in a user software application are describedherein. For example, it may be desirable to automatically modify thenative code module in order to determine or obtain various types ofinformation regarding execution of the native code module, e.g., formonitoring or debugging purposes.

The user software application may be implemented using both virtualmachine bytecode and native code. For example, the user softwareapplication may be implemented with bytecode where possible, and thebytecode may invoke native code routines when it is necessary to usefeatures dependent on the host computing environment. As describedbelow, the native code module may be dynamically modified duringexecution of the user software application, e.g., when the native codemodule is accessed by the virtual machine bytecode.

FIG. 1 is a flowchart diagram illustrating one embodiment of the method.As indicated in block 31, access to the native code module may bedetected during execution of the virtual machine bytecode of the usersoftware application. For example, the virtual machine bytecode mayaccess the native code module by invoking execution of the native codemodule or a native code routine in the native code module, or mayotherwise cause the native code module to be accessed or loaded.

As indicated in block 33, the native code module may be automaticallymodified by adding additional code operable to determine informationregarding execution of the native code module. The additional code addedto the native code module is referred to herein as instrumentation code.In various embodiments the instrumentation code may be operable todetermine or obtain any of various kinds of information regardingexecution of the native code module.

For example, the native code module may be modified by addinginstrumentation code operable to determine one or more of: profilinginformation for the native code module; debugging information for thenative code module; tracing information for the native code module;monitoring information for the native code module; instrumentationinformation for the native code module; information regarding aprogrammatic call performed by the native code module; a parameter valuepassed in a programmatic call performed by the native code module; etc.

As further examples, the native code module may be modified by addinginstrumentation code operable to determine one or more of: timinginformation for the native code module; invocation count information forthe native code module; performance information for the native codemodule; memory usage information for the native code module; resourceusage information for the native code module; network usage informationfor the native code module; database access information for the nativecode module; data used in the native code module; etc.

In some embodiments, modifying the native code module may includeautomatically analyzing the native code module, e.g., in order todetermine what additional code should be added to the native code moduleand/or where to add the additional code. Conventional techniques may beused to automatically analyze the native code module and addinstrumentation code operable to determine execution information for thenative code module.

As indicated in block 35, the method may further comprise directing theaccess detected in block 31 to the modified native code module. Forexample, the modified native code module or a routine within it may beexecuted, as indicated in block 37. Executing the modified native codemodule may include executing the instrumentation code that was added inblock 33. The instrumentation code may execute to determine theexecution information for the native code module.

The method may further comprise receiving and displaying the executioninformation determined by the instrumentation code, as indicated inblock 39. For example, in some embodiments a presentation tool mayreceive the execution information and may display a graphical userinterface on a display device, where the graphical user interfacedisplays the execution information. The execution information may bedisplayed during execution of the user software application and/or afterthe execution has finished.

The method may also or may alternatively comprise logging or storing theexecution information, as indicated in block 41. For example, after theexecution information has been determined it may be written to a logfile or stored in a database for future access.

FIG. 2 illustrates one embodiment of a computer system 80 that isconfigured to implement the method of FIG. 1. In various embodiments thecomputer system 80 may comprise any type of computer system. Thecomputer system 80 may include one or more processors 120 coupled tomemory 122. In some embodiments, the memory 122 may include one or moreforms of random access memory (RAM) such as dynamic RAM (DRAM) orsynchronous DRAM (SDRAM). However, in other embodiments the memory 122may include any other type of memory instead or in addition.

The memory 122 may be configured to store program instructions and/ordata. In particular, the memory 122 may store bytecode 205 for a usersoftware application, e.g., a software application created by a user(e.g., an application developer). In various embodiments the bytecode205 may comprise any type of bytecode, e.g., may comprise bytecodeconfigured to execute on any of various types of virtual machines. Forexample, in some embodiments the bytecode 205 may comprise Javabytecode, e.g., bytecode for a Java Virtual Machine (a virtual machineconstructed in accordance with a published Java Virtual Machinespecification). As another example, in some embodiments the bytecode 205may comprise Common Intermediate Language (CIL) bytecode for a CommonLanguage Runtime (CLR) virtual machine, such as bytecode for a Microsoft.NET software application.

The memory 122 may also store one or more native code modules 206 usedin the user software application. As used herein, the term “native codemodule” refers to a software module, component, or routine that includesnative code. The term “native code” refers to program instructionscompiled for execution by physical hardware, e.g., as opposed to beingcompiled for execution by a virtual machine. Examples of native codemodules include native code libraries, native code software components,native code classes, native code methods, and native code functions.

One or more of the native code modules 206 may be modified withinstrumentation code operable to determine execution information. Forexample, in some embodiments a native code module 206 may be modified atthe time it is loaded for use by the user software application, e.g.,where the native code module 206 is invoked from the bytecode 205 of theuser software application.

In some embodiments the memory 122 may also store a virtual machine 215.The virtual machine 215 may execute or interpret the bytecode 205 of theuser software application. In other embodiments, the bytecode 205 may bedynamically converted to native code and executed directly by theprocessor 120. For example, in some embodiments the bytecode 205 may becompiled into native code using a just-in-time compilation techniquethat compiles portions of the bytecode 205 into native code as neededduring execution of the user software application.

In some embodiments the memory 122 may also store a native codeinstrumentation tool 212. The native code instrumentation tool 212 maybe operable to automatically analyze a native code module 206 and modifythe native code module 206 by adding instrumentation code operable todetermine or obtain information regarding execution of the native codemodule 206. The native code instrumentation tool 212 may be invokedduring execution of the user software application, e.g., may be invokedto automatically modify a respective native code module 206 when thebytecode 205 of the user software application programmatically accessesthe respective native code module 206.

In some embodiments the memory 122 may also store a bytecodeinstrumentation tool 210. The bytecode instrumentation tool 210 may beoperable to receive bytecode 205 and automatically modify the bytecode205 by adding additional bytecode, where the additional bytecode isoperable to detect access of a native code module 206 by the bytecode205 and cause the native code module 206 be automatically modified byadding instrumentation code for determining execution information forthe native code module 206. For example, the additional bytecode mayinvoke the native code instrumentation tool 212, which performs themodification of the native code module 206. In an embodiment in whichthe bytecode 205 comprises Java bytecode, the bytecode instrumentationtool 210 may utilize Java bytecode instrumentation techniques toautomatically add the bytecode that performs the functionality ofdetecting the access to the native code module and invoking the nativecode instrumentation tool 212.

In some embodiments the memory 122 may also store apresentation/management tool 214. When a modified native code module 206is executed, the instrumentation code added to the native code model 206may determine various kinds of execution information regarding executionof the native code module 206. The presentation/management tool 214 mayreceive the execution information and perform various functions such asdisplaying the execution information in a graphical user interface,logging the execution information, etc. For example, displaying orlogging the execution information may enable a user to monitor or debugexecution of the native code module 206. In some embodiments thepresentation/management component 214 may also be operable to display aconfiguration user interface that allows the user to specify what typesof execution information should be automatically determined or otheroptions affecting the determination of the execution information and maycommunicate with the native code instrumentation tool 212 to pass thisinformation and configure it to modify native code modules 206accordingly.

Referring again to FIG. 1, it is noted that the processor 120 isrepresentative of any type of processor. For example, in someembodiments, the processor 120 may be compatible with the x86architecture, while in other embodiments the processor 120 may becompatible with the SPARC™ family of processors. Also, in someembodiments the computer system 80 may include multiple processors 120.

The computer system 80 also includes or is coupled to one or morestorage devices 125. In various embodiments the storage devices 125 mayinclude any of various kinds of storage devices operable to store data,such as optical storage devices, disk drives, tape drives, flash memorydevices, etc. As one example, the storage devices 125 may be implementedas one or more disk drives configured independently or as a disk storagesystem. In some embodiments the storage devices 125 may storerepresentations of the user software application bytecode 205, nativecode modules 206, and various other components before these componentsare loaded into the memory 122, and/or the storage devices 125 may storeportions of these components paged out from the memory 122 using pagingtechniques.

The computer system 80 may also include one or more input devices 126for receiving user input from a user of the computer system 80. Theinput device(s) 126 may include any of various types of input devices,such as keyboards, keypads, microphones, or pointing devices (e.g., amouse or trackball). The computer system 80 may also include one or moreoutput devices 128 for displaying output to the user. The outputdevice(s) 128 may include any of various types of output devices ordisplay devices, such as LCD screens or monitors, CRT monitors, etc.

In some embodiments the computer system 80 may also include networkconnection hardware 129 through which the computer system 80 connects toa network. The network connection hardware 129 may include any type ofhardware for coupling the computer system 80 to the network, e.g.,depending on the type of network. In various embodiments, the computersystem 80 may be coupled to any type of network or combination ofnetworks.

FIG. 3 is a flowchart diagram illustrating a more particular embodimentof the method of FIG. 1. It is noted that the blocks illustrated in FIG.3 may be performed in various orders, and various blocks may beperformed concurrently or repeatedly.

In 301, virtual machine bytecode 205 of the user software applicationmay be received by the bytecode instrumentation tool 210.

In 303, the bytecode instrumentation tool 210 may automatically analyzethe bytecode 205 to detect program instructions that performprogrammatic access of a native code module 206. For example, thebytecode instrumentation tool 210 may detect loading of the native codemodule or invocation of a routine in the native code module.

The access to the native code module 206 may be detected in variousways, e.g., depending on the particular type of bytecode 205. In someembodiments, detecting the access may comprise detecting one or moreprogrammatic calls (e.g., function calls or method calls) that accessthe native code module 206. In some embodiments the bytecode 205 may beimplemented on a virtual computing platform that provides an interfacefor invoking native code modules, and the access to the native codemodule 206 may be detected by detecting use of the interface. Forexample, in some embodiments the bytecode 205 may include Java bytecodethat accesses the native code module 206 through Java Native Interface(JNI), and the access to the native code module 206 may be detected bydetecting use of the Java Native Interface.

In 305, the bytecode instrumentation tool 210 may automatically addadditional bytecode to the bytecode 205 of the user softwareapplication, where the additional bytecode is operable to cause thenative code module 206 to be dynamically modified when the native codemodule 206 is accessed by the bytecode 205.

As indicated in 307, the additional bytecode added to the bytecode 205may be executed during execution of the user software application, e.g.,may be executed in response to or just prior to the bytecode 205attempting to access the native code module 206. The additional bytecodemay execute to invoke the native code instrumentation tool 212, whichmay automatically modify the native code module 206 by addinginstrumentation code operable to determine various types of informationregarding execution of the native code module 206.

In some embodiments the native code module 206 may be cached after ithas been modified by the native code instrumentation tool 212. Cachingthe modified native code module 206 may enable the modified native codemodule 206 to be reused for future access without needing to re-modifythe native code module 206, thus providing performance advantages.

The access request that was detected by the additional bytecode in block307 may be directed to the modified native code module 206, and themodified native code module 206 may be executed, as indicated in 309.Executing the modified native code module 206 may include executing theinstrumentation code added by the native code instrumentation tool 212.As described above, the instrumentation code may execute to determineinformation regarding the execution of the modified native code module206.

As indicated in 311, the presentation/management tool 214 may receiveand display the execution information determined by the instrumentationcode added to the native code module, and/or the presentation/managementtool 214 may store the execution information, e.g., in a log file ordatabase.

In various embodiments, the functionality of analyzing the bytecode 205of the user software application and adding the additional bytecode asdescribed above with reference to blocks 303 and 305 of FIG. 3 may beperformed in any of various ways. For example, in some embodiments theadditional bytecode may be statically added to the previously existingbytecode 205 before the user software application is launched forexecution.

In other embodiments, the additional bytecode may be dynamically addedto the previously existing bytecode 205 during execution of the usersoftware application. For example, in some embodiments, the usersoftware application may utilize object-oriented classes, where theclasses may be dynamically loaded during execution of the user softwareapplication. When a class is loaded, the class may be automaticallyanalyzed to detect whether the class or a method in the class accesses anative code module 206. If so, then the bytecode that implements theclass may be automatically modified, e.g., by adding additional bytecodethat invokes the native code instrumentation tool 212 to modify thenative code module 206 when the native code module 206 is accessed.

FIG. 4 is a flowchart diagram illustrating one embodiment of a methodfor dynamically adding the additional bytecode to an object-orientedclass used by bytecode 205 of the user software application.

In 401, the method of FIG. 4 may detect when the class is accessed forloading. For example, in some embodiments a class loader module mayaccess the class when the class is needed during execution of the usersoftware application.

In response to detecting the access of the class, the method of FIG. 4may operate to de-compile the class into a high-level representation.For example, the class may be de-compiled into source code or intotokens or structures representative of source code from which thebytecode of the class was created.

In 405, the high-level representation may be automatically analyzed inorder to detect programmatic access to the native code module 206. Forexample, in some embodiments the high-level representation may beanalyzed to detect whether the class includes one or more methods thatutilize a native code interface for invoking native code modules.

In 407, the class may be re-compiled with added functionality tointercept the request to access the native code module 206 and invokethe native code instrumentation tool 212 to modify the native codemodule 206 before it is loaded. For example, source code or otherinformation for performing this functionality may be added to thehigh-level representation, and the class may then be re-compiled so thatit includes the added functionality. Thus, re-compiling the class mayproduce the additional bytecode that intercepts the request to accessthe native code module 206 and invokes the native code instrumentationtool 212.

In 409, the modified class may be loaded. Thus, when the bytecode of theclass executes, the additionally added bytecode that intercepts therequest to access the native code module 206 and invokes the native codeinstrumentation tool 212 may also execute.

As noted above, in some embodiments, the bytecode of the user softwareapplication may be bytecode constructed for execution on a Java VirtualMachine (JVM). When a Java class is loaded during execution of the usersoftware application, the class may be analyzed in order to determinewhether any of the methods in the class access a native code module,e.g., by loading a native code library or invoking a method in a nativecode library through the Java Native Interface (JNI). For eachrespective method that accesses a native code module, the bytecode thatimplements the method may be automatically modified by adding additionalbytecode operable to intercept the request to access the native codemodule and invoke the native code instrumentation tool 212 in order tomodify the native code module with instrumentation code as describedabove. For example, Java bytecode instrumentation techniques may be usedto automatically add the additional bytecode.

Thus, when the method of the class is executed the additional bytecodemay intercept the request to access the native code module, invoke thenative code instrumentation tool 212 to modify the native code module,and cause the access request to be directed to the modified native codemodule. When the modified native code module executes, theinstrumentation code that was added by the native code instrumentationtool 212 may determine information regarding execution of the nativecode module. This execution information may be displayed on a graphicaluser interface or logged, e.g., where the execution information enablesa user to monitor or debug the execution of the native code module.

It is noted that various embodiments may further include receiving,sending or storing instructions and/or data implemented in accordancewith the foregoing description upon a computer-accessible storagemedium. Generally speaking, a computer-accessible storage medium mayinclude any storage media accessible by a computer during use to provideinstructions and/or data to the computer. For example, acomputer-accessible storage medium may include storage media such asmagnetic or optical media, e.g., disk (fixed or removable), tape,CD-ROM, DVD-ROM, CD-R, CD-RW, DVD-R, DVD-RW, etc. Storage media mayfurther include volatile or non-volatile memory media such as RAM (e.g.synchronous dynamic RAM (SDRAM), Rambus DRAM (RDRAM), static RAM (SRAM),etc.), ROM, Flash memory, non-volatile memory (e.g. Flash memory)accessible via a peripheral interface such as the Universal Serial Bus(USB) interface, etc. In some embodiments the computer may access thestorage media via a communication means such as a network and/or awireless link.

Although the embodiments above have been described in considerabledetail, numerous variations and modifications will become apparent tothose skilled in the art once the above disclosure is fully appreciated.It is intended that the following claims be interpreted to embrace allsuch variations and modifications.

1. A computer-accessible storage medium including program instructionsexecutable to implement a method comprising: detecting access to anative code module during execution of virtual machine bytecode of asoftware application; automatically modifying the native code module inorder to determine information regarding execution of the native codemodule; and directing the access to the modified native code module. 2.The computer-accessible storage medium of claim 1, wherein the methodimplemented by the program instructions further comprises: receivingfirst virtual machine bytecode of the software application; andautomatically adding additional bytecode to the first bytecode, whereinthe additional bytecode is operable to detect the access to the nativecode module and cause the modification of the native code module.
 3. Thecomputer-accessible storage medium of claim 2, wherein the additionalbytecode is operable to invoke a software tool that performs theautomatic modification of the native code module.
 4. Thecomputer-accessible storage medium of claim 2, wherein the methodimplemented by the program instructions further comprises: automaticallyanalyzing the first bytecode to detect program instructions that performthe access of the native code module; wherein the additional bytecode isautomatically added to the first bytecode in response to detecting theprogram instructions that perform the access of the native code module.5. The computer-accessible storage medium of claim 2, wherein the methodimplemented by the program instructions further comprises executing theadditional bytecode during execution of the software application,wherein the additional bytecode executes to detect the access to thenative code module and cause the modification of the native code module.6. The computer-accessible storage medium of claim 5, wherein executingthe additional bytecode comprises executing the additional bytecode on avirtual machine.
 7. The computer-accessible storage medium of claim 2,wherein the additional bytecode is automatically added to the firstbytecode during execution of the software application.
 8. Thecomputer-accessible storage medium of claim 2, wherein the additionalbytecode is automatically added to the first bytecode prior to executionof the software application.
 9. The computer-accessible storage mediumof claim 1, wherein the first bytecode includes bytecode implementing afirst method; wherein automatically adding the additional bytecode tothe first bytecode comprises automatically inserting at least a portionof the additional bytecode into the bytecode implementing the firstmethod.
 10. The computer-accessible storage medium of claim 1, whereinthe native code module comprises one or more of: a native code library;a native code software component; a native code method; a native codefunction.
 11. The computer-accessible storage medium of claim 1, whereindetecting the access to the native code module comprises one or more of:detecting loading of a native code library; detecting invocation of anative code routine.
 12. The computer-accessible storage medium of claim1, wherein automatically modifying the native code module in order todetermine the information regarding execution of the native code modulecomprises automatically modifying the native code module in order todetermine one or more of: profiling information for the native codemodule; debugging information for the native code module; tracinginformation for the native code module; monitoring information for thenative code module; instrumentation information for the native codemodule; information regarding a programmatic call performed by thenative code module; a parameter value passed in a programmatic callperformed by the native code module.
 13. The computer-accessible storagemedium of claim 1, wherein automatically modifying the native codemodule in order to determine the information regarding execution of thenative code module comprises automatically modifying the native codemodule in order to determine one or more of: timing information for thenative code module; invocation count information for the native codemodule; performance information for the native code module; memory usageinformation for the native code module; resource usage information forthe native code module; network usage information for the native codemodule; database access information for the native code module; dataused in the native code module.
 14. The computer-accessible storagemedium of claim 1, wherein automatically modifying the native codemodule comprises automatically adding additional code to the native codemodule, wherein the additional code is operable to determine theinformation regarding execution of the native code module; wherein themethod implemented by the program instructions further comprisesexecuting the modified native code module, wherein the additional codeadded to the native code module executes to determine the information.15. The computer-accessible storage medium of claim 14, wherein themethod implemented by the program instructions further comprises:displaying the information determined by the additional code added tothe native code module on a display device.
 16. The computer-accessiblestorage medium of claim 1, wherein the method implemented by the programinstructions further comprises: caching the modified native code module.17. The computer-accessible storage medium of claim 1, wherein thevirtual machine bytecode of the software application comprises bytecodefor a Java Virtual Machine (JVM).
 18. The computer-accessible storagemedium of claim 1, wherein the virtual machine bytecode of the softwareapplication comprises bytecode for a Common Language Runtime (CLR)virtual machine.
 19. A system comprising: one or more processors; andmemory storing program instructions; wherein the program instructionsare executable by the one or more processors to implement a methodcomprising: detecting access to a native code module during execution ofvirtual machine bytecode of a software application; automaticallymodifying the native code module in order to determine informationregarding execution of the native code module; and directing the accessto the modified native code module.
 20. A method comprising: detectingaccess to a native code module during execution of virtual machinebytecode of a software application; automatically modifying the nativecode module in order to determine information regarding execution of thenative code module; and directing the access to the modified native codemodule.